Several things comes to mind:

• Some qp solvers are parametrized, a string is therefore not enough to define it.
• Some qp solvers (proxsuite) already do regularization with a decay of the reg_eps, so this parameter could be a parameter of the solver itself
• some users may want to implement their own solver (which might be very imprecise with max_iter=1 for instance) and we cannot provide an exhaustive list of all ideas that could happen
• we may want the default solver to depend on what solvers are installed.

For this reason, I think we should define a (possibly private) class DualConeProjector(ABC, Callable[[Tensor, PSDMatrix], Tensor]) which would project weights. Then we can inherit from it to implement a specific solver. I think we can then provide a collection of solvers (or constructors of solver when they are parametrized).

For this reason, I think we should define a (possibly private) class DualConeProjector(ABC, Callable[[Tensor, PSDMatrix], Tensor]) which would project weights. Then we can inherit from it to implement a specific solver. I think we can then provide a collection of solvers (or constructors of solver when they are parametrized).

That would be very clean!

The other possibility would be to provide the necessary arguments as **kwargs so that they can be transmitted to the solver. Much more friendly to the beginner user, but less so to the experienced user probably.

I really don't know which one we should go for.

Closing in favor of #678